
\chapter{Introduction}
	The concept of a design pattern as a reusable solution to a recurring problem was 
	first introduced by Christopher Alexander in the field of architecture 
	(\cite{alexander1977pattern}). 
	His book gives design patterns such as \pattern{Outdoor Room}, 
	or \pattern{Arcades} to architects. 
	Although firstly used in the domain of architecture, over last two decades, 
	design patterns have gained popularity also in computer science, 
	especially in object-oriented design and programming. 
	
	\emph{This thesis is about design patterns in object-oriented design 
	and programming and in the following text the term "pattern" or "design pattern" 
	refers to these kinds of patterns.}
	
	In general \cite{gamma1995design}, a design pattern consists of
	\begin{itemize}
		\item{a name to provide a common vocabulary,}
		\item{a description of a problem and it's context,}
		\item{a proved and widely-accepted solution to this problem,}
		\item{the consequences of applying the pattern.}
	\end{itemize}
	
	A design pattern provides a solution that cannot be implemented in a generic library 
	or a framework. The abstract ideas behind a pattern are implemented again and again 
	but in each concrete case a little bit differently. If we take the \pattern{Composite} 
	pattern as an example, the problem it solves is to 
	let clients treat individual objects and compositions of objects uniformly. 
	The solution of the \pattern{Composite} pattern suggests to create 
	a \pattern{Composite} class that composes children components and 
	delegates it's operations to these children components. 
	Note that the pattern's solution, in this case, does not say how exactly 
	the composite operation must be implemented. 
	The operation \inlinecode{getWidth} may return the width of the largest component, 
	or it may return the mean of all widths. But one thing that should be fulfilled is 
	that the composite operation uses it's children components to do it's work and 
	this fact should be transparent to the clients. To make the example complete, 
	let us mention one of the consequences. The \pattern{Composite} pattern 
	makes it easier to add new kinds of components.	
	
	The main aim of patterns in object-oriented design is to make the design 
	reusable and flexible. This is very important because changes in the 
	functional requirements of software during the development, or requests 
	for new features in an already developed software are quite usual these days. 
	The mentioned consequence of the \pattern{Composite} pattern could be an 
	evidence for this aspiration of design patterns.
	
	In programming a typical mistake is to spend a fair amount of time by 
	solving something that has already been solved by someone else. 
	Patterns, among reusable libraries, frameworks and others, address and 
	partly solves this problem. Another advantage of patterns is the common language, 
	or common vocabulary. It makes the communication between developers much more effective when 
	all of them understand what the \pattern{Visitor} pattern is. 
	Even if two developers understand the complex logic behind this pattern, 
	it would take them some time to find out that they both mean the same 
	concept if they didn't know the common name for this pattern.
			
	Since the first notable publication about patterns in the field of 
	object-oriented design by so-called Gang of Four 
	\cite{gamma1995design}, there has been a great number of books about patterns 
	each focusing on a different kind of patterns. For example, 
	so called business patterns described in \cite{hruby2006business}, 
	or the enterprise patterns from \cite{fowler2002patterns}. 
	The principles discussed in \cite{evans2004domain} might be as well considered 
	as patterns, although on a higher level of abstraction than the original design patterns. 
	We could continue to enumerate more of them. In this thesis we mainly focus 
	on the design patterns as described in \cite{gamma1995design}, 
	where the authors define a design pattern as a
	\begin{quotation}
	description of communicating objects and classes that are customized to 
	solve a general design problem in a particular context.
	\end{quotation}
				
	One of the disadvantages of design patterns is that they bring a new 
	complexity into the design. This complexity is caused by 
	an introduction of new classes and interfaces in 
	order to provide better flexibility and reusability. 
	Developers often don't have enough time to create a 
	documentation for their classes and so the mapping between classes and a 
	design patterns is lost. The other members of the development team can 
	only study the source code, or reverse-engineered diagrams, but neither 
	of these emphasize the design patterns structure, which would provide more 
	abstract view and thus tackle some of the complexity. 
		
	Even if the code documentation includes information about implemented patterns, 
	an incorrect understanding of some design patterns by one of the development 
	team members may slow down the development process or even lead to 
	an introduction of software bugs in the system. For instance, when 
	one part of the system expects the objects of a specific type to be immutable, 
	but a developer unaware of what the immutability means changes this behavior. 
	In this case a formal verification might help.
			
	While tools for a formal verification and tools for tackling the complexity of 
	design patterns exist, they were mainly developed as research prototypes 
	and, except for few of them, they didn't get enough attention from the industry. 
	Moreover, most of these tools target the Java platform, but only few 
	target the .NET platform.	
		
	Some of the reasons why the industry is not adopting design patterns 
	verification tools may be too much mathematical formalism involved in 
	their usage. For a definition of new patterns, the knowledge of formal logic 
	is usually required. Tools for tackling the complexity of design patterns 
	are mostly based on an automatic recognition of design patterns, 
	whose advantage is that it does 
	not require additional work from developers and can be used for legacy systems, 
	but it's disadvantage is that it cannot correctly 
	recognize all the design patterns, since the differences between some of 
	them are only semantical (the \pattern{Bridge} and the \pattern{Adapter} 
	patterns) and some patterns, such as the \pattern{Command} pattern, are 
	too much abstract to be recognized only from the source code \cite{taibi2007design}. 
		
	The problems described in the previous paragraphs are addressed by the 
	Patterns4Net project, whose presentation is the main aim of this thesis. 
	Besides this, we also provide a brief overview of existing approaches 
	for design patterns formalization, which is needed for formal verification 
	and tool support, and we give a few examples of existing tools that provide 
	support for design patterns. 
		
	\section{Patterns4Net}		
		Experienced developers who use design patterns make usually this intention 
		explicit by some kind of documentation. For instance, leaving a note 
		"this class is immutable" in an API documentation may prevent the other developers 
		in a team from making the class mutable, or the fact that another class implements 
		the \pattern{Composite} pattern may direct the developer to implement a new 
		operation by delegating it to a collection of components, which should be present in 
		the \pattern{Composite} class. 
		
		An information about implemented pattern can also be helpful when a new 
		developer in the team tries to understand the overall architecture of the software project. 
		Some design patterns usually represent an infrastructural detail rather 
		than a domain specific code. On the other hand, if we also consider the patterns 
		used in the Domain-driven-design approach, these are mainly represented by 
		domain specific classes, which are important for an overall picture 
		of the architecture. 
		
		Unfortunately documentation in natural language is not understandable for 
		software, but some kind of standardized documentation of design patterns 
		implementation would be. 
		The main conception behind the Patterns4Net is that developers will 
		annotate their code using .NET attributes mechanism and the Patterns4Net 
		will provide tools that will take advantage of this documentation and 
		will support the development process.
		
		Patterns4Net provides two main tools. Pattern Enforcer verifies some 
		of the structural aspects of selected design patterns implementation and 
		Architecture Explorer generates interactive UML-like class diagrams 
		from .NET assemblies. This tool uses the information about 
		design patterns implementations to generate more abstract and 
		high-level diagrams than standard UML reverse engineering tools.
	
	\section{Thesis structure.}		
	In the following chapter we discuss 
    design patterns support in development process in general. 
	For precise patterns support and reasoning 
	about patterns, it is crucial to have a formal definitions of patterns and so  
	we explore patterns formalization techniques in 
	the section \ref{sec:patterns-formalization}. 
	The role of programming languages in the design patterns implementation is 
	discussed in the section \ref{sec:coding-support}. 
	Reasons for tools support in the design patterns based development and 
	limitations of existing tools form the content of the 
	section~\ref{sec:toolssupport}
	
	Third and fourth chapter focus on concrete tools developed as a 
	part of Patterns4Net. Namely Pattern Enforcer in 
	third chapter and Architecture Explorer in fourth chapter. 
	In both cases we firstly present features of the selected tool, 
	then a few use-cases, architecture of the tool and finally 
	comparison or related work.
	
	Description of the Graphviz4Net a graph visualization tool for .NET,
	which was developed for Architecture Explorer, is provided in the 
	fifth chapter.
		
	In the conclusion we summarize the thesis and suggest future work.
	
	
